RESTful APIのError Response

のデザイン

エラーをレスポンスに含める方法

headerに含める

bodyに含める

エンベロープの言及はあったが、実際に様々なサービスではbodyに含められていることが多い

こういうフォーマット良さそう

code:error

error: {

developperMessage: string; // 開発者向けのエラーメッセージ

userMessage: string; // ユーザー向けのエラーメッセージ

code: number // 400,404とか

info: string // 参考リンクなど

}

messsageよりもkindのようなもののほうがいい気もする

両方でもいい

clientによってエラーメッセージを変更したいというのはありうる

その分岐がしやすければ良い

以下の2種類がある

project全体で共通のerror message

API固有のerror message

これらの両方を扱えるように設計しないといけない

また、この2つのエラーはある程度interfaceが揃っている必要がある

ただ、このinterfaceのルールは業務で扱っているプロダクトの多岐に影響するので、最低限のものにしたい

5個も規定があると修正できない

型レベルで、どれが来たのか判定できるようにしたい

status codeレベルの粗さで十分なのか？という疑問はある

clientで、status code以上に細分したくなった場合、この4つのfieldだけでは不十分だと思う

code:error

error: {

developperMessage: string; // 開発者向けのエラーメッセージ

userMessage: string; // ユーザー向けのエラーメッセージ

code: number // 400,404とか

info: string // 参考リンクなど

}

400番台

clientに問題がある

どのように対応するかはclientの責任

そのため、error messageは親切であるほうが好ましい

500番台

server側に問題がある

clientは何の対応もできない

そのため、error messageは詳細にすべきでない

詳細にしたところで、clientは何もできないし

詳細にすると、セキュリティ上のリスクもある

返り値に、statusを含めるのは冗長か？

status codeはheaderから受け取れる

しかし、こっちで見ると型が弱くなる

「値を見る前にstatus codeを確認せよ」は運用カバーになる

強制できない

こういうinterfacceにしておけば運用カバーではなく強制にできる

code:ts

type Result<R, E> =

| { status: 'ok', value: R }

| { status: 'error', message: E}

普通にstatus codeでやり取りすべき

世の中のものがそうなっているのでそれに合わせたらいい

isSuccessとかはが必要なら、clientでそういう関数を噛ませるべき

いろいろなサービスのレスポンス比較

配列にしておくと、複数のエラーを表現できる